Various enum fixes - #8803

@dstogov Would you prefer if backed_enum_table was part of zend_class_mutable_data? zend_class_entry.backed_enum_table would always be NULL though if mutable data is used, so it seems unnecessary.

I didn't get how enums are become mutable, but if we have mutable constant tables for regular classes, we may reuse them for enums as well.

@dstogov To clarify, the enum cases themselves are stored in zend_class_mutable_data.constants_table. zend_class_entry.backed_enum_table in PHP <8.2 has been static. In GH-8190 we moved the compilation of the backed_enum_table to the runtime to allow arbitrary expressions referencing symbols from other files. Like constants we do that on every request. The difference is that when using the inheritance cache zend_class_entry.constants_table contains the constant ASTs while backed_enum_table is just NULL and thus unused, so moving it to zend_class_mutable_data seems useless.

Note that my understanding of the inheritance cache is spotty, so maybe I'm missing something.

Personally I would prefer if backed_enum_table was in zend_class_mutable_data.

Normally any zend_class_entry may be in SHM and should not be modified. Enums disable the inheritance cache so the linked zend_class_entry is not in SHM in this case, but I think that it would improve clarity if the code didn't depend on this knowledge.

@arnaud-lb I decided not to move the backed_enum_table into mutable_data but instead assert that the class is not ZEND_ACC_IMMUTABLE. mutable_data is only used for internal enums because they need to avoid replacing the constant AST of the cases in-place. The backed_enum_table is actually constant and not modified after class construction. For user classes ZEND_ACC_IMMUTABLE is always disabled and thus it's fine to set the backed_enum_table directly. I hope that makes sense.